home *** CD-ROM | disk | FTP | other *** search
/ STraTOS 1997 April & May / STraTOS 1 - 1997 April & May.iso / CD01 / INTERNET / SITES / RAND / ALL96.LZH / t0111 / text0021.txt < prev    next >
Encoding:
Text File  |  1996-03-07  |  7.5 KB  |  146 lines
  1.  
  2. This is mainly a reply to Magnus' comments to my comments :)
  3.  
  4. In retrospect, after reading your reply, I guess I have to agree that we
  5. are both right. There will always be _some_ people on an open mailing list
  6. like this that will be unable to contribute with much of use, but I guess
  7. I was a bit too pessimistic when it comes to the percentage of people who
  8. fall into that category.
  9.  
  10. But still, the number of people on the list, we have learned, is about 40,
  11. and the number of people who regularly post anything (Including me, since
  12. I believe I'll try to make myself a little useful from now on) is not
  13. really that high (I'd guess about 15 regulars).
  14.  
  15. > I just want to get some response so that the list doesn't die. I know it's a
  16. > fine line to walk, but I hope I havn't stepped on to many toas. I would 
  17. > hate to see this project slowly die as it's of great interest to the rest of
  18. > the atari (falcon) world.
  19.  
  20. That I must absolutely agree on! This project might have a great impact on
  21. several aspects of the great international society of Falcon (OR Atari)
  22. owners. First of all, it shows that there's still a keen interest in
  23. making good programs (Not solely games) for our beloved platform. Second,
  24. the co-operation of so many people from different countries proved to me
  25. that that Atari scene still is bright and active, and that people are
  26. willing to help each other out when they need aid. These two main aspects
  27. together show that the Atari will not be dead for quite some time yet, at
  28. least not in our hearts, and that might persuade some people who have
  29. doubts about the Falcon to buy one, or to keep one if they intended to
  30. sell it.
  31.  
  32. > And look! You did write some very interesting things now and I
  33. > havn't seen your name before. That shows that there is some programmers out
  34. > there having good ideas.
  35.  
  36. True, true. I mean, it's not very surprising that you haven't seen my name
  37. before, since I have mainly been quite anonymous in the Atari society
  38. since I finally made it onto the net about eighteen months ago. I believe 
  39. there are many like me, too.
  40.  
  41. > I do also suspect that we have got several good
  42. > demo coders with us that might want to help with some cool things. :-)
  43.  
  44. Again, true. The problem is just to make them aware of this project, and
  45. persuade them to lend a hand. (I was about to write "lend us a hand", but
  46. I suppose it'd be wrong of me to use the word "us" in that context ;-) The
  47. reasons why we should ask demo coders to look into the project is quite
  48. simple: They have the experience that so many of us lack. The 3D-routs of
  49. EKO are just about the best I've ever seen, and getting an experienced
  50. demo-coder to hand us a quick routine for sprites should be a piece of
  51. cake. Provided the request comes from someone who really knows them. And
  52. I, unfortunately, don't.
  53.  
  54. > Sadly, I will probably fall into that category that isn't of any programing use,
  55. > since I only program in C. :-|
  56.  
  57. Hmmm... Someone asked if the networking modules could be programmed in C,
  58. and I believe they could. Choosing GCC would undoubtedly be the best,
  59. though the GEM environment of Pure C makes coding easier. (Perhaps a first
  60. try in Pure C and then porting would be the way to go...)
  61.  
  62. To get a bit technical here, passing parameters from the Bad Mood main
  63. program to a resident networking module is not hard - if a parameter
  64. buffer is initialized prior to the loading of the networking module, and
  65. the address of that buffer is passed to the module as it is loaded, it
  66. would be easy (Probably) to make this following idea work...
  67.  
  68. Consider a resident networking module that attaches itself to an interrupt
  69. (eg. VBL) and does two things:
  70. 1: It listens to whatever port it is initialized to listen to, and if
  71.    something is coming in, it somehow tells the host program (Bad Mood) that
  72.    something has come in, and transfers it to an incoming buffer before
  73.    passing it on to the next machine in the network (Remember that in case
  74.    of a Midi network, multiple Falcons can be networked in a circle, and
  75.    since messages can only be sent one way they must pass through all the
  76.    machines until it gets back to the originating machine, which will
  77.    then NOT send it out again ;-)
  78. 2: It waits for the host program to request the transmission of a package to
  79.    the other machines in the network, and when requested to do so, sends it
  80.    out.
  81. This fairly simple idea can be made possible the easy way. The parameter
  82. buffer that can be used for communication between module and host program
  83. could look like this ( Simple C structure ) :
  84. struct {
  85.   int incoming = 0 ;    /* Flag checked by host prog: !=0 => Incoming true */
  86.   int outgoing = 0 ;    /* Flag checked by module: !=0 => Outgoing true    */
  87.   int acknowledge = 0 ; /* Ready flag for comm. Module <==> host program   */
  88.   long *inbuffer ;      /* Pointer to the incoming buffer                  */
  89.   long *outbuffer ;     /* pointer to the outgoing buffer                  */
  90.   int buf_size ;        /* Could be a long, but not necessary              */
  91. } net_parameter ;
  92. I'm fairly certain most people on this list see where I'm heading. This
  93. structure is designed to make expansion easy. I'll give a more in-depth
  94. explanation of my idea for the code to anyone who asks for it.
  95.  
  96. And now about the protocol to be used:
  97.  
  98. > Maybe you could think about that too? If I understand it right you need to
  99. > know what direction the players are heading and there they are and if
  100. > the fire or not. The collision detection will be calculated on each machine.
  101. > You will also need to know if someone have activated any switches. Maybe this
  102. > is to simple, but something like that.
  103.  
  104. It would be easy to transmit raw binary data between the machines, so an
  105. as simple as possible protocol would be the best choice. (As optimized as
  106. possible, either concerning speed or size) But in addition to just passing
  107. the data, a few more things need to be transferred: To avoid having a
  108. package being sent in circles again and again we need to know which
  109. machine originally sent it. Since the best idea would be to let each
  110. machine's networking module be oblivious to the number of opponents (Only
  111. the bad Mood program itself needs to know that. I have already thought if
  112. how to best organize the best initial initialization of the network...
  113.  
  114. > Why not contact Doug your self? I know he and Dave Murphy have discussed
  115. > some crazy ideas about networking. He would also know which data need
  116. > to be transferd to make it work.
  117.  
  118. I suppose it's now pretty clear that I'm interested in helping out on the
  119. networking modules, so if anyone have any ideas to comapre to mine, please
  120. send me a note. Right now, however, I'm rather soon on my way to class (Oh
  121. this darn college) so I don't think I'll have the time to write another
  122. e-mail.
  123.  
  124. > > Anybody have any comments on this? Flames can be directed to me,
  125. > > personally (I have some negative experiences from writing to mailing lists
  126. > > earlier... Ouch, was I scorched!)
  127. > I don't think you will get any flames. :-)
  128. > I have also got burned sometimes. That is a part of the game... ;-)
  129.  
  130. True yet again - I forgot I was on an Atari mailing list! Not many of us
  131. ever write flames to each other! 8-)
  132.  
  133. Well, that's it for this mail. I see one mor ething I'd like to comment
  134. on, but I'll take that in another short posting...
  135.  
  136. Kai
  137.  
  138. =====================================================================
  139. Kai Trygve Holst           # These are not the views of HiAa - They
  140. P.O.Box 5061, Larsgaarden  # are Copyright (C) 1995, Kai Trygve Holst
  141. N-6021 Aalesund, Norway    # "The fairest rose is picked the first"
  142. http://www.hials.no/~kh/   # "Time is the silentmost enemy of youth"
  143.  
  144.  
  145.  
  146.